home *** CD-ROM | disk | FTP | other *** search
- Path: grafix.xs4all.nl!john.hendrikx
- Date: Wed, 14 Feb 96 01:44:56 GMT+1
- Newsgroups: comp.sys.amiga.misc
- Distribution: world
- Subject: Re: MUI 3.2
- MIME-Version: 1.0
- Content-Type: text/plain; charset=iso-8859-1
- Content-Transfer-Encoding: 8bit
- From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
- Message-ID: <john.hendrikx.4ebh@grafix.xs4all.nl>
- Organization: Grafix Attack BBS Holland
-
- In a message of 11 Feb 96 Paul Copsey wrote to All:
-
- >> CM> I agree. When I really looked, my ENV: was using up 600k. I have now
-
- >> 600 kilobytes? Could you please send me a LIST of your ENV dir? I'm
- >> REALLY interested to see what stuff is in there. My ENV dir is 20000
- >> bytes, containing 73 files and 11 directories. The MUI part is less than
- >> 3K. The largest file ENV: contained was 1146 bytes.
-
- PC> My env: contains 33226 bytes of files, but actually uses 138240 bytes
- PC> because of the way filesystems work. If I had Env: in Ram: (I use
-
- RAM uses its own filesystem, it doesn't use FFS or something like that.
-
- Try writing a 10 byte file to RAM and use Avail to see how much space was used.
- You'll find that it takes between 100-200 bytes to do this. A larger file
- (say 100 bytes) will take 200-300 bytes. The overhead for the file-header is
- about 150 bytes (a 30 char name, a 80 char comment, and some other stuff).
-
- PC> statram, which has a block size of 512, as opposed to Ram:'s 1024) then
- PC> env: would swallow 247808 bytes.
-
- RAM doesn't actually use 1K blocks, some programs just 'think' that it does
- because they would probably crash if RAM told them that it doesn't use "blocks"
- at all.
-
- PC> Even a 1 byte file in ram: will take 1k to store.
-
- Not on my system (Kick 3.0). Have you actually verified this or did you just
- assume that it does?
-
- There is something strange though, if you create a file of 0 bytes then it
- takes 1K to store on RAM. A 1 byte file however will only take 100-200
- bytes... try it.
-
- Grtz John
- -- Via Xenolink 1.985B5, XenolinkUUCP 1.1
-